fix(rr): decouple agentSandbox postgres from externalSecret (use postgres.urlSecretName); require encryption key by JatinNanda · Pull Request #331 · tryretool/retool-helm

JatinNanda · 2026-06-12T23:01:54Z

what

setting rr.agentSandbox.externalSecret.name (intended just for the JWT keypair) silently overloaded two unrelated things, breaking enablement on a deployment that only wanted to reuse its existing backend postgres:

postgres hijack — postgresUrlEnv routed AGENT_SANDBOX_POSTGRES_URL to the external secret's postgres-url key. missing key → getaddrinfo ENOTFOUND at runtime. the inherit-the-backend path was unreachable whenever externalSecret.name was set, and validateSecrets counted it as an explicit pg source so nothing failed at template time.
encryption key was treated as optional — but it isn't. the proxy derives the sandbox-iframe asset-token HMAC key from AGENT_SANDBOX_ENCRYPTION_KEY (agent_executor/proxy/src/config.ts getAssetTokenHmacSecret) and throws the first time it serves a sandbox if it's missing. the pod comes up green and then fails at first use.

separately, the snapshot blob-storage env never reached the workflow worker, even though the agent/snapshot temporal activities run there.

changes

externalSecret.name now covers only the JWT/encryption keys — it never sources postgres. to read a DSN from that same secret, point postgres.urlSecretName at it (Option 3; urlSecretKey defaults to postgres-url). otherwise postgres inherits config.postgresql — an existing deployment needs no DB config.
require the agent sandbox encryption key in validateSecrets (mirrors the JWT-key checks) — fail loudly at render instead of shipping a pod that breaks at first sandbox use; both fail hints point at postgres.urlSecretName
render gitServer.commonEnv (RR_DEFAULT_*) onto the workflow worker when rr.gitServer.enabled. the agentExecutor/snapshotRetention temporal activities run on WORKFLOW_TEMPORAL_WORKER and read snapshot blob storage (getBlobStoreForSnapshots, RR_SNAPSHOTS_* → RR_DEFAULT_* fallback), but commonEnv was only injected onto the backend + standalone git-server pod — so the worker had no creds and snapshot access failed there.
values.yaml (both copies): drop postgres-url from the externalSecret.name key list, mark encryptionKey required (64 hex, openssl rand -hex 32)
bump chart 6.11.1 → 6.11.2; update ci/ fixtures to supply the now-required encryption key

incorporates #332

pulled in @ryanartecona's passwordSecretName support so the two don't collide. in the final shape it lives in the postgres.urlSecretName branch: the blueprints case (DSN from the agent-sandbox secret, password from the auto-rotated main secret) is postgres.urlSecretName: agent-sandbox-env + postgres.passwordSecretName: retool-config.

note: an earlier revision used a postgres.fromExternalSecret boolean — redundant with postgres.urlSecretName, since removed in favor of it.

testing

helm template verified: urlSecretName routes to the secret's postgres-url (+ PGPASSWORD when passwordSecretName set); JWT-only externalSecret inherits the backend DSN; render fails with a clear error when no encryption-key source is set; the workflow worker now renders RR_DEFAULT_* when gitServer.enabled + blobStorage is set. all ci/ fixtures render; helm lint clean.

note: same-origin-on-HTTPS (a separate reported issue) is a backend gap, not chart-fixable, and is out of scope here.

🤖 Generated with Claude Code

greptile-apps · 2026-06-12T23:04:27Z

Greptile Summary

This PR fixes two silent runtime failures in the rr.agentSandbox Helm stack: (1) externalSecret.name was previously hijacking the Postgres DSN source, making the inherit-backend path unreachable; (2) the encryption key was treated as optional even though the proxy throws on first sandbox use without it.

Postgres decoupling: removes the externalSecret.name → postgres-url branch from postgresUrlEnv; operators who want a DSN from that same secret now use postgres.urlSecretName (Option 3), and the existing fallback to config.postgresql works as before. Pulls in passwordSecretName support for the urlSecretName path from Respect postgres.passwordSecretName in presence of rr.agentSandbox.externalSecret #332.
Encryption key enforcement: adds a validateSecrets guard that fails at helm template time with an actionable message, mirroring the existing JWT-key checks.
Workflow worker blob-storage env: injects retool.gitServer.commonEnv (RR_DEFAULT_*) onto the workflow worker when gitServer.enabled, so agentExecutor/snapshotRetention temporal activities can reach blob storage.

Confidence Score: 5/5

Safe to merge; the changes tighten validation and eliminate a silent mis-routing, with no existing working configuration broken.

The core change (removing the externalSecret→postgres-url fallback and adding encryption-key validation) is well-tested by the updated CI fixtures, all of which exercise different Postgres-sourcing paths. The two observations raised are a minor env-var ordering inconsistency and a broader-than-described scope for the gitServer.commonEnv injection — neither affects runtime correctness.

_helpers.tpl — the new postgresUrlEnv urlSecretName+passwordSecretName block and validateSecrets encryptionKey check are the highest-impact additions; worth a careful read-through.

Important Files Changed

Filename	Overview
charts/retool/templates/_helpers.tpl	Core template changes: decouples externalSecret from Postgres sourcing, adds encryptionKey validation, and fixes postgresUrlEnv to remove the externalSecret→postgres-url fallback branch; new passwordSecretName support in the urlSecretName path.
charts/retool/templates/_workers.tpl	Injects retool.gitServer.commonEnv (RR_DEFAULT_* blob-storage vars) onto all workers when gitServer.enabled; consistent with how agentSandbox.backendEnvVars was already applied.
charts/retool/values.yaml	Removes Option 4 (externalSecret→postgres-url), marks encryptionKey as REQUIRED, updates Option 3 comment to clarify passwordSecretName interaction.
values.yaml	Mirror of charts/retool/values.yaml changes; identical diff.
charts/retool/ci/test-agent-sandbox-enabled-option.yaml	Updated to add postgres.urlSecretName pointing at the same secret as externalSecret.name, correctly demonstrating Option 3 alongside an external secret.
charts/retool/ci/test-agent-sandbox-inherit-postgres-option.yaml	Adds the now-required encryptionKey to this fixture; no other changes.
charts/retool/ci/test-agent-sandbox-postgres-fields-option.yaml	Adds the now-required encryptionKey to this fixture; no other changes.
charts/retool/ci/test-rr-enabled-option.yaml	Adds the now-required encryptionKey to this fixture; no other changes.
charts/retool/Chart.yaml	Version bumped from 6.11.2 to 6.11.3.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[agentSandbox.enabled] --> V[validateSecrets]

    V --> PG{explicit postgres?<br/>url / host / urlSecretName}
    PG -- yes --> OK_PG[Postgres source resolved]
    PG -- no --> INHERIT{config.postgresql<br/>host resolvable?}
    INHERIT -- no --> FAIL1[💥 fail: set url/host/urlSecretName]
    INHERIT -- yes --> PWD{password via<br/>external envFrom?}
    PWD -- yes --> FAIL2[💥 fail: set url/urlSecretName/host]
    PWD -- no --> INHERIT_OK[inherit backend postgres]

    V --> ENC{encryptionKey or<br/>externalSecret.name?}
    ENC -- neither --> FAIL3[💥 fail NEW: proxy throws at first sandbox use]
    ENC -- either --> OK_ENC[encryption key resolved]

    OK_PG --> ENV[postgresUrlEnv]
    INHERIT_OK --> ENV

    ENV --> URL[postgres.url → literal value]
    ENV --> HOST[postgres.host → assemble DSN + PGPASSWORD]
    ENV --> URLSEC[postgres.urlSecretName → secretKeyRef<br/>optional: passwordSecretName]
    ENV --> DEF[default: inherit config.postgresql]

    style FAIL1 fill:#f66,color:#fff
    style FAIL2 fill:#f66,color:#fff
    style FAIL3 fill:#f66,color:#fff

_{Reviews (5): Last reviewed commit: "chore(rr): bump chart version to 6.11.3 ..." | Re-trigger Greptile}

ryanartecona · 2026-06-13T00:07:46Z

uhhh what do you think about instead of rr.agentSandbox.postgres.fromExternalSecret: true, we just mirror the pattern we have for other stuff already and introduce rr.agentSandbox.postgres.urlSecret{Name,Key}? that is IMO more flexible & straightforward with the slight tradeoff of being slightly more verbose.

…s; require its encryption key setting rr.agentSandbox.externalSecret.name (intended for the JWT keypair) silently (a) routed the agent sandbox postgres connection to that secret's postgres-url key and (b) coupled the encryption key to it. an existing deployment that just wanted to reuse its backend postgres crashed at runtime with getaddrinfo ENOTFOUND. - postgres now only reads from externalSecret when postgres.fromExternalSecret: true (default false); otherwise it inherits the backend's config.postgresql connection, even when externalSecret.name is set for the JWT - require the agent sandbox encryption key (validateSecrets, mirroring the JWT keys): the proxy derives the sandbox-iframe asset-token HMAC key from AGENT_SANDBOX_ENCRYPTION_KEY and throws when serving a sandbox without it (agent_executor/proxy/src/config.ts getAssetTokenHmacSecret), so 'optional' would surface as a green pod that fails at first sandbox use. fail loudly at render instead. - updated both validateSecrets fail hints to mention postgres.fromExternalSecret: true - values.yaml (both copies): add postgres.fromExternalSecret, mark encryptionKey required, note 64 hex - bump chart 6.11.1 -> 6.11.2; update ci fixtures to supply the now-required encryption key and add fromExternalSecret: true to the Option-4 sandbox fixture

…ternalSecret (cherry picked from commit 38304c0)

…cretName the fromExternalSecret boolean was redundant with the existing Option-3 postgres.urlSecretName/urlSecretKey: 'read postgres-url from externalSecret.name' is identical to pointing urlSecretName at that same secret (urlSecretKey already defaults to postgres-url). drop the bespoke flag and the externalSecret postgres branch entirely, so externalSecret.name covers ONLY the JWT/encryption keys and never sources postgres. - remove rr.agentSandbox.postgres.fromExternalSecret (both values.yaml copies) - postgresUrlEnv: delete the externalSecret postgres branch; move the passwordSecretName PGPASSWORD support (#332) into the urlSecretName branch, so 'DSN from a secret + auto-rotated password from another secret' uses Option 3 - validateSecrets: drop the externalSecret term from $explicitPg; repoint both fail hints to postgres.urlSecretName - ci: test-agent-sandbox-enabled-option uses postgres.urlSecretName (Option 3) pointed at its JWT secret instead of the removed flag

the agentExecutor / snapshotRetention temporal activities run on the WORKFLOW_TEMPORAL_WORKER (registered in workflowsExecutor/onpremWorker) and read snapshot blob storage via getBlobStoreForSnapshots (RR_SNAPSHOTS_* with an RR_DEFAULT_* fallback). but gitServer.commonEnv was only injected onto the main backend and the standalone git-server pod, so the worker had no RR_DEFAULT_* and snapshot blob access failed there -- forcing operators to hand-plumb RR_SNAPSHOTS_* via env. include gitServer.commonEnv on the worker when rr.gitServer.enabled (no git-server host/port split -- the worker is a blob-storage client, not the git server). self-guards on rr.blobStorage being set, so it no-ops otherwise.

JatinNanda force-pushed the fix-rr-agent-sandbox-secret-overload branch from 7fb7343 to 78fc2ad Compare June 12, 2026 23:10

JatinNanda changed the title ~~fix(rr): stop agentSandbox externalSecret.name from hijacking postgres~~ fix(rr): stop agentSandbox externalSecret.name from hijacking postgres; require its encryption key Jun 12, 2026

JatinNanda force-pushed the fix-rr-agent-sandbox-secret-overload branch 3 times, most recently from e70c5cf to bd0f3a3 Compare June 12, 2026 23:44

JatinNanda marked this pull request as ready for review June 13, 2026 00:02

JatinNanda requested a review from ryanartecona June 13, 2026 00:02

JatinNanda changed the title ~~fix(rr): stop agentSandbox externalSecret.name from hijacking postgres; require its encryption key~~ fix(rr): agentsandbox secret & postgres sourcing — opt-in external postgres, required encryption key, passwordSecretName support Jun 13, 2026

JatinNanda changed the title ~~fix(rr): agentsandbox secret & postgres sourcing — opt-in external postgres, required encryption key, passwordSecretName support~~ fix(rr): decouple agentSandbox postgres from externalSecret (use postgres.urlSecretName); require encryption key Jun 13, 2026

JatinNanda and others added 5 commits June 12, 2026 20:41

Respect postgres.passwordSecretName in presence of rr.agentSandbox.ex…

b0619b4

…ternalSecret (cherry picked from commit 38304c0)

chore(rr): bump chart version to 6.11.3 (rebased past #333)

f3e4341

JatinNanda force-pushed the fix-rr-agent-sandbox-secret-overload branch from a5890ea to f3e4341 Compare June 13, 2026 00:42

lukefoster11 approved these changes Jun 15, 2026

View reviewed changes

JatinNanda merged commit baf5e8a into main Jun 15, 2026
20 of 24 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(rr): decouple agentSandbox postgres from externalSecret (use postgres.urlSecretName); require encryption key#331

fix(rr): decouple agentSandbox postgres from externalSecret (use postgres.urlSecretName); require encryption key#331
JatinNanda merged 5 commits into
mainfrom
fix-rr-agent-sandbox-secret-overload

JatinNanda commented Jun 12, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Jun 12, 2026 •

edited

Loading

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Flowchart

Uh oh!

ryanartecona commented Jun 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

JatinNanda commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

what

changes

incorporates #332

testing

Uh oh!

greptile-apps Bot commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 5/5

Important Files Changed

Flowchart

Uh oh!

ryanartecona commented Jun 13, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

JatinNanda commented Jun 12, 2026 •

edited

Loading

greptile-apps Bot commented Jun 12, 2026 •

edited

Loading